IBIS Macromodel Task Group

Meeting date: 03 May 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Ming Yan
                              Radek Biernacki
                            * Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
SAE ITC                     * Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Michael (Mike) McNair introduced himself.  He is currently serving as VP for
  Aerospace at SAE ITC (IBIS's parent organization).  He said his background was
  in systems engineering and embedded software.  He had developed device drivers
  and other low-level software that was close to the hardware.  He was joining
  to learn more about what we do.

-------------
Review of ARs:

- Michael Mirmak to create draft 2 of BIRD219.1 containing the meeting's changes
  and send it to the ATM list.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 26th
meeting.  Ambrish moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD219.1 draft 2 AMI Parameter Root Name Clarifications:
Walter gave a general overview of ATM and this topic to help Mike McNair.  He
said there are three broad categories in the IBIS community: model makers, EDA
tool makers, and end users/consumers.  Walter said he had worked in all three
areas, and that one persistent feature of ATM meetings is that model makers and
tool vendors are generally better represented than end users.

Walter said the issue at hand is what to do when an AMI model is not being used
correctly.  When the tool calls the model, it passes in a parameters string in
AMI_parameters_in.  When the model's call returns, it passes back a string in
AMI_parameters_out.  The root name of the strings should match each other and
match the root name from the .ami parameters file.  What should be done if they
don't match?  What should the model do if the tool passes in an unexpected root
name? What should the tool do if the model passes back an unexpected root name?

Arpad concurred with the summary and noted one additional point.  In forward-
looking discussions in the Quality task group, the idea of a .dll supporting
multiple sets of functionality had been explored.  In that scenario, the root
name itself might serve an AMI Selector (analogous to [Model Selector]) in the
future.

Walter said the BIRD's author, Michael Mirmak, had run into difficulty with
models doing strange things if they received an unexpected root name.  He'd also
found that tools may behave differently and produce different results if they
received an unexpected root name back from the model.  This BIRD wants the model
and the tool to detect and report issues with the root name.

Walter said that as a model maker he knows what he has to do.  He has to return
a message string in the msg parameter.  Unfortunately, lots of messages could
already exist in that string.  So, he suggested we might put something special
in the string (e.g., "*** Error ***") to make it clear to the EDA tool that a
message requires priority handling.  Arpad asked whether we should define a
message numbering system similar to what the ibischk parser employs.  Walter
said he just wanted EDA tools and model makers to agree on a string identifier
so the EDA tool knows how to handle/display the message.

Arpad reminded everyone that at the previous meeting the obligation of the model
to report any mismatch had been reduced from a requirement to a suggestion.  He
asked Ambrish to state his case again, as he had been the only one to oppose the
requirement.  Ambrish said that we should avoid legislating what tools and
models "must" do unless it's necessary.  He said some models may simply not care
about the root name.  They shouldn't be obligated to check if they don't care.
We also don't need to standardize what type of message the model returns.  He
said there would be many places in the specification where we could do that, and
it would open Pandora's box.  Ambrish said that after last week's discussion we
decided not to mandate that the model check.  However, if the model does check
and care about the root name, then it should report a message in the event that
it receives something it doesn't like.  The message should indicate what it does
expect.  Otherwise, the user has no idea why the model balked.

Randy asked if this would be the first case of us specifying what the .dll's
message should contain.  Walter said that as a matter of course, all 7.2 models
he creates will return a message if they detect a root name mismatch, and the
message will have an indication that it's an error.  Walter said if the model
isn't required to return a message, then it wasn't worth trying to specify the
contents.  Randy said we could eventually create a whole guide to required
message formatting/content, but it would be beyond the scope of this BIRD.

After further group discussion, Walter said he was okay with the model not being
required to check the root name and return a message.  He said the tool could do
the checking.  The tool passes a root name in, and it gets a root name back.
If there's a mismatch, the tool can check and catch it.  Arpad asked if the tool
could catch an issue in the case of a model that simply always returned the same
root name it had received.  Walter and Ambrish said this would be a clear
indication of a model that did not care about the root name, and no checking was
required.

Arpad asked whether everyone agreed the current draft was ready to be submitted to
the Open Forum.  Randy moved to submit it to the Open Forum as BIRD219.1, with a
minor grammatical changed noted during the meeting.  Walter seconded the motion.
There were no objections.

- Walter: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

AR: Arpad to send the latest draft of BIRD219.1 to Randy to be submitted to the
    Open Forum as BIRD219.1.
    
-------------
Next meeting: 10 May 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
